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Something Special 
By John Ackermann, N8UR, n8ur@tapr.org 


If you missed Dayton this year, you missed something special. Forget 
about whether the attendance was up or down, and about the slightly 
damp weather. ’m talking about what happened in and around the 
TAPR booth, where the energy and creativity levels were inspiring. 


We had two guests at the booth this year. Gerald Youngblood, AC5OG, 
was demonstrating his SDR-1000 software defined radio, and Lyle 
Johnson, KK7P (you may remember him as WA7GXD), was showing 
off his new DSP engine. Gerald and Lyle are both people whose enthu- 
siasm is contagious, and they and their products drew a crowd. 


What was really cool was watching the light bulbs go on when people 
saw these products and realized what could be done with them. Eaves- 
dropping on the conversations around the booth showed that people 
were really intrigued by the SDR concept, and — this is important — 
were beginning to see it as something real and practical rather than as 
just an idea. 


802.11b Transverter 


A couple of issues ago, I wrote about the inevitable clash between 
increasing ham use of “WiFi” hardware on 2.4 GHz and the commercial 
interests who have staked out that unlicensed territory. I suggested that 
the answer might be found in a transverter that would move the WiFi 
signal to another ham band that we wouldn’t be sharing with Part 15 
usets. 


That column drew a lot of positive response, and we’ve been looking 
into the transverter idea. Discussions at the Dayton Hamvention with a 
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Continued from page 1 
number of microwave RF manufacturers indicate that the idea is certainly feasible, but there’s a big question 
whether we can come up with a product that will offer both performance and price that are tempting to hams. 


We’re continuing conversations that might lead to a commercially-produced transverter, but we’d also like to 
look into a simple transverter kit. Microwave RF projects can be quite simple to build because most of the 
tuned circuits can be etched right onto the PC board. 

There are a number of low cost “no tune” transverters available today. While they are designed for a differ- 
ent task than our transverter would be, they may show the way for us. If you know of — or happen to be — 
an RF-savvy ham looking for a challenge, we’d like to find some volunteers to take on a project like this. If 
you'd like to help out, please drop us a line. 

It’s DCC Time 


It’s not too late to make your plans for the DCC, but time is running short. The ARRL/TAPR Digital Com- 
munications Conference will be held September 19-21 in Hartford, Connecticut, and it’s shaping up to be a 
great show, with excellent presentations and a first-rate keynote speaker at the banquet. See elsewhere in this 
issue for more details. 


That’s it for now. See you at the DCC! 


73, John ft 


Call for TAPR Board of Directors Nominations 


Nominations are now open for TAPR Board of Director seats expiring this year, t.e., the seats held by John 
Koster, W9DDD, Brad Noblet, WA8WDQ, and Steve Stroh, N8GNJ. 


Board members serve three-year terms and their responsibilities include: 


1) Attendance at both board meetings each year. (One is held at the Dayton Hamvention in May, the other at 
the Digital Communications Conference in September.) 

2) Regular participation in the continuous board session, which is conducted over the Internet. 

3) Active engagement in TAPR’s management. 

To place a person in nomination, please remember that he or she must be a member of TAPR. Also, confirm 
that the individual is willing to have his or her name placed in nomination. Send that person’s name (or your 
own if you wish to nominate yourself), call sign, mailing address, e-mail address, phone number(s), and a 
biographical sketch (100 words maximum) via e-mail to tapr@tapr.org or to the TAPR office (P. O. Box 
852754, Richardson, TX 75085-2754) no later than August 24, 2003. If you submit a nomination via e-mail, 
we strongly encourage you to follow up by regular mail. 3 
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Digital Communications Conference Taking Shape 


By Steven Bible, N7HPR, n7hpr@tapr.org 


HARTFORD, Connecticut - July 24, 2003 - The 
22nd Annual ARRL/TAPR Digital Communications 
Conference slated for September 21-23, 2003 in 
Hartford, Connecticut is taking shape. 


At the heart of the conference are technical presen- 
tations by amateurs and experimenters alike on the 
many technical projects they are working on. Techni- 
cal papers are solicited for presentation and publica- 
tion in the proceedings. Annual conference proceed- 
ings are published by the ARRL. Presentation at the 
conference is not required for publication. Submis- 
sions of papers are due by August 5th, 2003. Submis- 
sion guidelines are available on the DCC web page 
www.tapr.org/dcc. 


The DCC guest speaker is Alex Mendelsohn, AI2Q, 
Senior Technology Editor at ChipCenter 
(www.chipcenter.com). Alex wrote an interesting 
atticle titled “NASA, NORAD, Amateur Radio, and 
Me” (www.chipcenter.com/ 
TestandMeasurement/ed024.html) in which he 
notes first hand that amateurs are movers and shakers 
in many levels of industry. Some are presidents of 
leading-edge technology companies. Others are 
engineers and technicians sweating in R&D labs, large 
and small. 


Several introductory seminars are scheduled 
throughout the DCC to introduce new technical 
topics for beginners and experts alike. Here are some 
of the introductory seminars scheduled: 


Intro to WSJT by Del Schier, KIUHF 

Intro to EchoLink and VoIP by Jon Taylor, KIRFD 
Intro to PSK31 by Steve Ford, WB8IMY 

Intro to APRS by Stan Horzepa, WA1LOU 


There will also be an APRS Networking mini-seminar 
moderated by WA1LOU. The seminar will address the 
many networking options available to the APRS user 
and how networking decisions effect the operation of 
the APRS network. Finally, it will make recommenda- 
tions on optimal network settings for various APRS 
environments. 


Software Defined Radio will be the topic of the four- 
hour Sunday Seminar. Matt Ettus, N2MJI, will give live 
demonstrations of software-defined radio, explain what 
it is, and how you can design and develop your own 
projects. Matt is involved with the GNU Radio project 
(www.gnu.org/software/gnuradio/gnuradio.html), 
Hamlib (http://hamlib.sourceforge.net), and others. 


Amateurs and experimenters alike are highly encout- 
aged to write about their projects and submit them for 
publication in the DCC Proceedings. 


Mote information about the DCC can be found at 
www.tapr.org/dcc. 


Alex Mendelsohn, AI2Q, noted technology editor 
and author tr 
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Try This On For Size 
By Wes Johnston, KD4RDB, wes@johnston.net 


Hidden transmitter problems have plagued packet radio since its start. APRS is growing in popularity and the 
local 2-meter networks are becoming saturated. Throw mobile stations with poor receiving range into the mix 
and you'll soon have a network crippled by collisions. Any collision leads to a packet with an improper 
checksum and causes that packet and the interfering packet to both be discarded. 


Packet was designed to be CSMA (Carrier Sense Multiple Access) just like Ethernet. The problem is that 
often some stations assume a channel is clear because they do not hear any activity. When those stations 
transmit, they could prevent a nearby digipeater from hearing a packet from a station still further away. With 
the popularity of APRS and it’s use of mobile transmitters, the problem has gotten worse. To put it clearly, 
mobile stations do not hear very well and end up causing QRM. Particularly with APRS’s use of UI frames, 
data cannot be resent in the event of a collision. 


To check your local APRS network’s coverage, make use of the RAW.CGI script available at 
www.findu.com/cgi.html and the BREADCRUMB.CGI. RAW.CGI has an option to show timestamps of 
received packets and can be used to check for missing packets. BREADCRUMB.CGI can be used to check if 
coverage is available in a given area. For example, on my commute to work, I thought we had no digipeater 
coverage over a large portion of my trip. A quick check on findu.com with the breadcrumb script revealed that 
there was indeed coverage at every point along my trip. The reason for intermittent position reports was 
caused by transmitters that I could not hear from the area in question. My rig transmitting at the wrong times 
was causing collisions. 


The Europeans have adopted DAMA (Demand Assigned Multiple Access) to address hidden transmitter 
problems. DAMA is suitable for connected mode links only, and not effective for APRS’s “come as you are” 
methods. Some DAMA documentation strongly discourages UI frames on a DAMA channel. 


To date, only one solution has been attempted to alleviate collisions on an unconnected and uncoordinated 
channel. GPS time slotting is a workable solution, but only if you have a GPS hooked to your station, and 
then only if you choose a time slot that no one else occupies. Practically speaking, there must be a coordinat- 
ing body that is responsible for issuing time slots. This method is used to coordinate a large number of APRS 
trackers at an event such as a foot race. 

Recently, a discussion came up on the TAPR APRSSIG about hidden transmitters. Three schools of though 
have emerged from this discussion. The first school of thought is to simply use smaller and smaller cells. The 
second uses multiple receivers at each digipeater site. And finally the third uses many remote receivers on a 
connected link to the main digipeater. 


Solution 1: Frequency Reuse Through Shorter Sites 

In the first proposed solution, more WIDE and RELAY digipeaters would be placed lower and closer to- 
gether. Ultimately, this would serve to limit the maximum distance a packet could travel. AX.25 allows 7 hops 
in the path, but only 3 or 4 are practical due to collisions. Reducing the range of a WIDE digipeater does have 


Continued on page 6 
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its advantages. Since the WIDE node can’t hear as far, it is less likely that two stations will try to access the 
WIDE at the same time. Even if the WIDE is hearing a distant station, the FM capture effect will allow the 
local mobile station to get into the WIDE digipeater if its signal strength is higher than the distant station. 


This concept will work if implemented with a backbone or if it can get packets to an IGATE (Internet 
gateway). Using a backbone would permit digipeaters to hear one another on a link frequency and to hear 
users on 144.39 MHz. As more of these types of linked digipeaters come on the air, it will become necessary 
to pass information from one segment of the network to another. Since the backbone would contain all data, 
it is simply a matter of requesting certain data from your local wide node and having that data selectively 
“gated” from the backbone to the user channel. This could be as simple as sending a message to the local 
digipeater periodically that requests that certain stations be “gated” out to the local network, or that certain 
data products, such as tides and weather from distant places be “gated” out to the local network. Of course 
these requests would timeout after a fixed interval. This would permit mobile users to request data from local 
networks as they pass through and the local networks would not stay busy if the requesting station was not 
around any longer. 


In other words, I could setup my mobile rig’s status message to periodically request the tides in Tampa Bay. 
As I travel, linked WIDE nodes hear this request and “gated” that data onto 144.39 for me to hear. As I 
continue to travel, other wide nodes begin to hear this periodic request and begin to pass this information 
from the backbone frequency to the local access frequency. The linked WIDE nodes from the areas I passed 
through in the past no longer hear my requests and within 30 minutes, cease passing the traffic I requested. All 
that is needed to implement this is the addition to the APRS specification to facilitate the requesting of spe- 
cific data products. Ninety percent of the programming is already implemented in the form of IGATES. 


Solution 2: Frequency Agile Mobile Stations 


The second solution to be discussed is to simply place multiple receivers at each digipeater. Several TNCs 
could be wired together in parallel so that each could access the transmitter at the digipeater site. Any TNC 
hearing a carrier would prevent the others from transmitting and any TNC transmitting would also prevent the 
others from transmitting. This is not as restrictive as it sounds. The additional receivers would not hear nearly 
as many packets as the primary TNC at a WIDE digipeater hears now. 


The point of holding off a TNC from transmitting if another is recetving a packet is to prevent the transmit- 
ter from desensing a receiver on the same band and causing a packet to be lost. Call sign substitution could be 
used to identify the entry point into the digipeater. Suggested call signs would include the six-digit frequency 
of the receiver or the word SATGATE, for example. Remember, only one radio is used here, so only one of 
the TNCs must ID its proper call sign. 


From a uset’s perspective, the system would require frequency agile equipment. This is easier that one might 
think. Simply tie the PTT line on your radio to the MIC-UP button. Program several memories in your radio 
with “odd-splits” that transmit on the digipeater’s input frequencies and listen on 144.39 MHz. Each time your 


TNC keys the radio, the radio advances to the next memory channel. 
Continued on page 7 
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The obvious difficulty with this concept is that each area may have different input frequencies. This has been 
addressed in the new OPENTRAC protocol. A digipeater would publish its alternative frequencies periodi- 
cally over the air and user equipment such as Kenwood D700s or D7As could be automatically programmed. 


The next question is which frequencies to use? As connected mode BBS systems have been shutdown, they 
have left largely unused ranges of frequencies in the 144.9 to 145.1 MHz range and the other packet sub- 
bands. Any unused frequency is a prime candidate. The downlink frequency of PCsat, 145.825 MHz, is an- 
other candidate. Also, it could be beneficial to “scavenge” packets from the output frequency of your local 2- 
meter and 70-cm repeaters in case there are any mic-encoder users on them. 


The end result of this proposal would be to reduce the likelihood of collisions by increasing the number of 
choices available to the mobile user’s equipment. 


Solution 3: Linked Remote Receiver 


The third solution most closely resembles a voice repeater’s use of remote receivers. In this system, a TNC 
at a short, limited range receive site would hear a packet. That packet would be presented on its serial port and 
in turn, passed along to a second TNC at the same site. This second TNC would operate in connected mode 
on 70 cm. 


The connected link between this TNC and the WIDE node would guarantee delivery of each and every 
packet heard at the remote site. It would be up to the WIDE digipeater to sort out duplicates and only publish 
one copy of a given packet even if it came in from multiple receiver sites. 


What happens when the WIDE node fails in this system? Recall that the second TNC at each remote site is 
operating in the connected mode. Should the link to the WIDE node fail, the “connected” LED will extin- 
guish. This can be hardwired to a relay that enables and disables the PTT line on the first (144.39 MHz) TNC 
at the site. The 144.39 MHz TNC would be setup to act as a WIDE node, but if connected to the community 
WIDE node, its PTT would be disabled in hardware. 


If that link failed, the 144.39 MHz TNC would have access to its 144.39 MHz radio and behave as a WIDE. 
In either case, copies of all packets received are sent out on the serial port and queued for delivery to the 
community WIDE node. Care must be taken to insure that no old packets are allowed to stay buffered in the 
second TNC should the link fail, and care must be taken that a packet originating from the community WIDE 
node is not forwarded back to itself in an endless loop. A simple PIC processor or BASIC stamp could be 
used to coordinate and filter packets to be forwarded. 

From the uset’s perspective, no equipment changes are needed. 

In conclusion, there are many ways to decrease collisions in the APRS network through geographic and 
frequency diversity. The methods detailed above are by no means the only solutions to this problem. Addi- 
tionally, the CGI scripts at www.findu.com are also valuable tools to use for network analysis to help deter- 
mine the best solution for your area. ft 


NZART Conference 


By Darryl Smith, VK2TDS, vk2tds@tapt.org 


In the last four years since I was in New Zealand, some things have changed in the ham radio world. The 
national society is in a better financial state and the hobby is once again starting to experiment with new 
modes. Back in 1999, there was almost no usage of APRS. Now this mode has close to 95% population 
coverage. 


Back then, my job was to publicize APRS. This time 
around it was to represent TAPR in an attempt to spur 
interest in newer aspects of the hobby. Like every- 
where, the NZART is growing older. However, because 
of the smaller ham population in general, the lack of 


younger members is somewhat magnified. 
Wellington 


What I need to explain here is that the national capital 
of Wellington, where the conference basically was held, 
is one of the most wired capital cities in the world 
thanks to an unauthorized project by the IT department 
of the local city council. Back in the early 1990’s, the IT 
manager started installing Ethernet cabling around the 
city at night on the poles used by the cities electric 
busses. Eventually, the project became an official 
project and became a fiber-optic backbone. 


Soe Ye 


Eom re ea 
tf | poe 


The network is continuing to expand with about 20 
wireless access points scattered around the city 
(www.cafenet.co.nz) allowing wireless access from a 
huge number of coffee shops in the city. 


For Internet access in Wellington and at the confer- 
ence, I purchased a prepaid Internet card from a local 
ISP. They provided a nationwide free call number for 


only about $1 per hour. This was a bargain. 


I did not realize that the CafeNet was so extensive when I bought that card. Whilst in Wellington, I was able 
to access this network for $20 for 120 Mbytes of traffic. They state that they hope to bring in 4 hours or 120 
Mbytes, but there is a lot more value from the per-Mbyte charge in my view. 


In Wellington, my hotel room faced the wrong direction to maintain wireless signals without some help. The 
8-dBi omni provided the required gain when positioned in a window, but only when I worked out which side 


Continued on page 9 
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of the hotel the wireless signal was coming from. The other thing that took some time to work out was that I 
needed to use DHCP... When I run the wireless card at home, I normally use static addressing to make auto- 
mated use of my home access point a bit harder. 


What was also great was that my cell-phone worked as soon as I turned it on in the country - thanks to the 
joys of GSM Global Roaming. I was always amazed when people rang me, thinking I was at home and in fact, 
I was in another country. I am just glad that I have not seen the phone bill yet. 


In Wellington, they had just in the last week unveiled a sculpture as part of an arts program, a sculpture that 
may be of interest to people who are interested in digital codes. I am sure there is a message there and I 
suspect that it is actually in brail for the blind, but it is an example of binary codes in the real world. 


VHF Group Meeting 


On flying into the New Zealand capital of Wellington, I needed to present a talk to the local VHF group on 
the technology of 802.11b running at 2.4 GHz. As a catch phrase, I called the talk “High Speed Packet Radio 
at 2.4 GHz for under $50 (US$30)” ensuring some interest. Interest there was, with about 25 local members 
venturing out into the cold Wellington night. 


One of the highlights of this presentation was showing the club that 2.4 GHz experimentation was not hard. 
In the talk, I even built a 2.4-GHz antenna lab with an Access Point and NetStumbler. 


At this meeting, I made some very interesting people, who have some fantastic ideas for the use of GPS and 
APRS without the use of expensive equip- 
ment in their cars. It was fantastic to see 
people actually doing experimenting in 
groups. 

The Conference 


The conference itself was over the Queen’s 
Birthday weekend, about an hour north of 
Wellington. The conference was opened on 
the Saturday morning by the head of the New 
Zealand signals interception organization 
with a talk about the history of signals intelli- 
gence, the unclassified version. After that 
lecture, I was able to actually use an original 
ENIGMA machine as used by the Germans 
during WWII. In general though, this talk was 
a bit of a disappointment. Later, I found out 
that we got a “recruitment” talk. 


Continued on page 10 
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Following this talk was the NZART annual meeting, which I did not attend... I had some talks to complete at 
this time. In the early afternoon once the AGM was over, it was time for me to give my first talk. 


This talk was of general interest with a 10-minute segment on TAPR followed by a session about the radio in 
the Sydney Olympics. The choice of this talk was deliberate. It showed how ham radio was being used in the 
real world and is making a difference. This, along with lots of colorful pictures inside the presentation meant 
that the many spouses would also be interested in the talk. All in all, about 100 people turned up for this talk. 


The TAPR presentation I gave will soon be available on the TAPR www site. I just need to find time to 
finish it. 


Sunday morning, I gave what was probably the most important one of all, one that I started writing at the 
2002 DCC in Denver. The title of this talk was “Bazaar Ham Publicity” or how to publicize the hobby using 
the bazaar approach. It was rather disappointing that only about 10 to 15 people turned up to this talk. I can 
say that without a doubt that those that did turn up were challenged to change the hobby and have started to 
think about what the perceptions about ham radio are, and how to counter them. 


Personally, I was rather concerned about this talk because it is not one that I would call “polished.” I was 
asked about a week before the conference for a talk that could fit a timeslot, and that was what I came up with 
and my biggest concern was that it would only last 10 minutes. In the end, the talk lasted 50 minutes and the 
discussion went on much longer. People were still talking about the issues at breakfast the next day, something 
that is not really common for a lot of presentations. 


The universal view was that this talk should have been given to every ham at the conference. Some people 
were talking about flying me to a conference over the Easter long weekend solely to give this talk. 


Sunday afternoon, it was time for a talk on “High Speed Packet Radio” just like the earlier talk in Wellington. 
This went down really well and as always, the discussion came back to the regulatory environment. I found it 
really hard to tell these people that they have effectively lost the primary allocation in 2.4 GHz and need to 
fight to keep secondary status. 


One thing I was able to suggest was that they start looking at moving their “National System” from 70 cm to 
2.4 GHz. The National System covers most of the country and really is an amazing engineering effort giving 
most of the country access to a linked repeater system. By moving to a digital 2.4-GHz backbone, they could 
leverage the sort of applications only available with a countrywide data network. 


Conclusion 


Visiting New Zealand for the conference was no holiday for me, but it was really enjoyable. Many of the 
contacts that I have made over there now know that there is an international community out there doing 
things, and that they can assist. Just because it is isolated does not mean that the country is not producing 
some real innovations. 3 
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By Richard Parry, W9IF, w9if@arrl.net, http://w9if.net/cgi-bin/wapaprs/web_main.pl 


Abstract 


WAPaprs is an application to display APRS information on a cell phone that supports the Wireless 
Application Protocol (WAP). It was written to provide useful APRS data within the size, memory, color, 
and bandwidth limitations of a wireless handheld device. The paper includes a description of all menu 
options and example displays. 


Keywords 
APRS?, WAP, WML, Linux, Perl, Cellular Technology 
Introduction 


Few could have imagined in the early 80s that cellular communication would enjoy the popularity that 
it does today. A cellular phone, once thought of as a luxury, is now considered by many to be a neces- 
sity. As of early 2001, one out of 10 people in the world (680 million) used a cellular phone. Many 
Amateur Radio operators have joined the ranks of cellular phone users and find they are legitimate 
devices to supplement amateur communication. 


Cellular technology has come a long way in a brief time. First generation 
(1G) systems used analog technology. Although primitive and unreliable by 
today’s standards due to poor voice quality and frequent call drops, 1G showed 
that mobile communication for the masses was technically feasible and eco- 
nomically viable. 

The late 90s introduced second generation (2G) systems using digital tech- 
nology. This new generation brought substantial improvements to voice qual- 
A ity, call reliability, miniaturization, battery life, and heralded the beginning of 
= data services. 


| = = 
c_NextMap |_| At the dawn of the new millennium, third generation (3G) advanced digital 
systems are being deployed worldwide. This latest generation is characterized 


by improvements to system capacity, reliability, extended services, and significantly higher data rates. 
For example, 1xEV-DO, which is a 3G standard, supports rates in excess of 2 Mbit/s. These higher 
speeds mean that bandwidth hungry multimedia applications that were once limited to the desktop can 
be provided to the mobile user. 


Cell phones today, even low-end phones, can be used for more than just talking. A user can send and 
receive e-mail, surf the Internet, play MP3 music, and even send and receive color pictures using the 
latest generation of camera-ready phones. 

Continued on page 12 
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As an Amateur Radio operator and APRS aficionado, I was anxious to retrieve APRS data using a cell 
phone. WAPaprs is the result of my work. It provides the cell phone user the ability to retrieve informa- 


tion from the findu.com and aprsworld.net databases. 


WAPaprs Access 


Due to the relative difficulty to input text using a small cell phone keypad, the suggested method for 


using WAPaprs is to permanently bookmark call signs of interest. For example, if you often check the 
location of KC5PVL-9, permanently bookmark: http://w9if.net/cgi-bin/wapaprs/main?kc5 -pvl-9. 
Using this method, very few keystrokes are required to obtain the desired information. 


Alternatively, users can bookmark: http://w9if.net/cgi-bin/wapaprs/main ; in which case the user 


will be prompted to supply just a call sign. This significantly reduces the number of keystrokes. In the 


examples below, URLs are included to allow the user to access specific displays without first going to 
the main URL. I provide these URLs for completeness, but do not expect users to access WAPaprs in 


this manner. Generally, the user will start at the main WAPaprs display and navigate to other displays 


el WAP aprs 
WOIFS 
ie-osition 
2 Cities (US) 

3 Landmarks (US) 
4 Weather 

5 Maps BY 

6 Mans Color 


eae 


e) Position 
NOWST9 02:34 
Lat 40.79233 
Lon -89.60000 
Speed 5.5 mph 
Course NW(G11) 


with single keystroke responses. 


Main 

http://w9if.net/cgi-bin/wapaprs/main 

http://w9if.net/cgi-bin/wapaprs/main?w9if 

The “main” display can be accessed with or without a call sign. If a call sign is 
not provided, the user will be directed to another display and prompted to 
supply one. If a call sign is provided, a menu is provided to allow the user to 
select from one of seven options: Position, Cities, Landmarks, Weather, Maps 
(Black and White), Maps (Color), and New Call. The seventh option, New Call, 
is off the cell phone display in the figure to the left. 
Position 

http://w9if.net/cgi-bin/wapaprs/posit?w9if 

The “position” display shows the latitude, longitude, speed, and course of an 
APRS object. All information displayed comes from the findu.com database. 
The age of the packet is displayed in hours and minutes. In this example, the 
packet is 2 hours and 34 minutes old. Showing seconds was deemed to be 
unnecessary and of little value given the time for the transaction. The limited 
display on a cell phone was also a consideration in dropping the seconds infor- 


mation. 
Continued on page 13 
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Ve 

| 1B cities 

WS9IF4 00:25 
1-Sorrento, CA 1.5 
mi. ENE(65) 

2-La Jolla, CA 2.3 
omi. SSW(205) 
\3.Easter Cross, CA, 


' Ve, 
Sl Landmarks 
WS9IF-4 00:24 
1-Blacks Beach, 
CAO.2 mi. NYVIST?) 
2-Salk Institute, 
~CA0.3 mi. SE(128) 
3-Torrey Pines 
‘Glider pot, CA OB | 


8] Weather 
WSIF-4 00:01 
Direct 228 
Speed 2 mph 
Gust 5 mph 
Temp 60 F 
Rainthr 5.13 in 

Rain24hr in 


Continued from page 12 
Cities 

http://w9if.net/cgi-bin/wapaprs/cities? w9if 

The “cities” display allows the user to locate an APRS object in reference to 
neatby cities. The term “cities” is used loosely. Many of the locations are not 
cities, but populated areas. The information displayed comes from two sources. 
First, the findu.com database is accessed to obtain the latitude and longitude. 
From there, the aprsworld.net database is accessed to determine a nearby city. 
WAPaprs does this by calculating a “box” around the APRS object. If ten or more 
cities are located within the box, WAPaprs displays the closest ten cities. If there 
are less than ten cities nearby, the box is expanded until ten or more objects are 
located. The objects, along with the distance and direction are computed and 
displayed. 
Landmarks 

http://w9if.net/cgi-bin/wapaprs /Imarks?w9if 

The “landmarks” display is similar to the cities display. Both access the 
findu.com database to determine the latitude and longitude of the APRS object. 
They both access aprsworld.net, but use different databases. The landmarks 
database differs from the cities database in that the locations are not populated 
areas, but geographical locations of interest. For example, in the display to the 
left, Blacks Beach is a clothing optional beach in San Diego. The Salk Institute is 
the world famous institution founded by Jonas Salk, who was responsible for 
curing polio in the 50s. Like the cities display, the ten closest landmarks are 
shown along with the distance and direction to each landmark. 


Weather 

http://w9if.net/cgi-bin/wapaprs/wx?w9if -4 

The “weather” display shows weather conditions for APRS weather stations. The 
findu.com database is accessed for this information. The data displayed includes: 
age of packet, wind direction, wind speed, wind gust, temperature, rain, humidity, 


and pressure. 
Continued on page 14 
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Continued from page 13 
Maps (B&W) 

http://w9if.net/cgi-bin/wapaprs/mapbw?w9if 

The “maps” (B&W) display shows three map resolutions: 500’, 2,500’, and 2 
miles to the scale shown. One may question the usefulness of the small maps. 
However, the usefulness of the map really depends on the users requirements. 
In the example shown, the names of the street are not available, but the 
APRS object (shown as a circle) can be seen a few streets south of I1. There 
are many situations where that level of detail is useful and sufficient. The size 
of the map is approximately 70 x 90 pixels. Most Internet users are familiar 
with GIF and JPEG images. However, WAPaprs maps are WBMP (Wireless 
Bit Map) graphic files. WBMP images are used since they are the standard 
format supported by most WAP cell phones. 
Maps (Color) 

http://w9if.net/cgi-bin/wapaprs/mapcolor?w9if 

The “maps” color display shows three map resolutions identical to the B&W 
maps: 500', 2,500', and 2 miles. However, there are two major differences. 
First, the maps are in color. Second, the images are in GIF format rather than 
WBMP. While most WAP compliant cell phones support WBMP graphics, 
there is no guarantee the phone will support GIF images. For this reason, 
some users may find color maps are not displayed. However, today’s high-end 
cell phones that support GIF images will be tomorrow’s low-end phones. So I 
suspect it is just a matter of time before most users will be able to see these 
color maps. 


New Call 

http://w9if.net/cgi-bin/wapaprs/newcall 

The “new call” display allows the user to input a new call sign. I wish to 
emphasize again that few users will access this display or any of the other 
displays mentioned directly, with the exception of the main display. When a 
uset accesses the main display, he/she can easily navigate to all other pages 
including the “new call” display. Note that WAPaprs does not support wild 
cards such as W9IF* or W9IF-*. The limited viewing area of a cell phone 


makes displaying more than one APRS object impractical. 
Continued on page 15 
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Continued from page 14 


Terminology 


This section includes WAPaprs background information and nomenclature. It describes some of the unique 
terminology of WML and the WAPaprs architecture. 


WML (Wireless Markup Language) was used to create WAPaprs. WML is a formatting language similar to HTML. 
It is defined as an XML (Extensible Markup Language) document that is optimized for small screens and memory 
size. Although WML is similar to HTML, WML cannot be displayed directly on a desktop web browser such as 
Internet Explorer or Netscape because these desktop browsers support HTML not WML. A WAP enabled cell 
phone or WML emulator is the best way to correctly render WML. 


A WML document ts called a “deck”. A deck is similar to an HTML web page and is identified by a single URL 
(Universal Resource Locator). This means a deck shows a single screen on a cell phone. A deck consists of one or 
more “cards”. Of the seven WAPaprs displays, all are a single deck with the exception of the B&W and color map 
decks. The B&W map deck is made up of three cards. Each card displays a different map resolution. The same is 
true for the color map deck; it also consists of three cards. Each card displays a different color map. 


Software Development 


I include this section for those that may be interested in the WAPaprs software development process and tools 
used. This will aid those wishing to develop their own cell phone application. 


All WAPaprs displays use the Wireless Markup Language (WML). The language is very similar to HTML; in fact, 
many of the tags are identical. However, the language has been specifically created for wireless applications where 
bandwidth and transfer rates are critical requirements and need to be understood. As an example, while normal 
HTML source code is sent from a web server to a client as plain text that the user can read, WML source code is 
complied by a WAP gateway into a compressed binary file. The binary is more transmission efficient than sending 
plain text and therefore, reduces airtime and substantially increases throughput. 


It is possible to develop a WAP application using only a cell phone, but it is uneconomical due to the airtime 
required. It is also an inefficient use of development time. Fortunately, there are several options. The most popular 
WAP development tool is the Openwave Software Development Kit (SDI) available free of charge at 
www.openwate.com. This web site also serves as a great resource for cell phone development software and informa- 
tion. 
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Caveat 
Please do not use WAPaprs while driving! 3 
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Packet in the Real Worlt 
By Darryl Smith, VK2TDS, vk2tds@tapt.org 


For those that don’t know me, as well as a TAPR board member from Sydney, Australia, I am also a 
consultant engineer working in wireless technologies. What I have been finding recently is that there are 
an increasing number of Amateur Radio technologies making it into the real world 


The work has involved looking at sme GPS tracking devices using a satellite uplink to get the data back 
to the rest of the world. Since I have been dealing with these on the commercial side, I thought it might 
be useful to examine some of them from the commercial standpoint. 


Satellite Systems 


The system that I have been using is operated by a US-based company called OrbComm 
(www.orbcomm.com). They operate a constellation of about 35 satellites operating in low earth orbit 
(about 500 miles). The satellite themselves weigh about 45 kg, and operate on VHF with 2400 bit/s up 
and 4800 bit/s, as well as a VHF 56k downlink for command and control. The satellites operate with an 
uplink frequency of 148-150.05 MHz and a downlink frequency of 137-138 MHz. 


These satellites have a lot in common with the early AMSAT satellites, apart from the fact that these 
were mass-produced. They operate in two modes: Instantaneous Downlink, and Store-and-Forward. 


The Instantaneous Downlink mode allows long messages such as e-mail to be sent and received di- 
rectly from the earth station with the satellite acting as a digipeater. Since there are no downlinks in my 
part of the world, I have been unable to determine if the link layer is done on a per-hop basis, or for 
the entire up and downlink. It would make sense for them to be separate, but I have not been able to 
find out. 


The Store-and-Forward mode allows binary messages of up to 250 characters to be transmitted from 
anywhere in the world for downlinking the next time the satellite passes over a ground station. The 
message is then sent to a service provider for processing. 


What is unique with this mode is that the “from” call sign is just the serial number of the unit and the 
routing is dependant on a database maintained by OrbComm. The ability to add data to the packet to do 
additional routing makes possible routing to multiple recipients, but that is not the purpose of this 
mode. 


It is to allow telemetry to be delivered with a minimum of overhead. Where data is costing US$1.40/ 
kbyte, adding a long e-mail address to the start of a packet is wasteful. Therefore, this data format 
assumes that the service provider that OrbComm sends the data to will know what to do with it. In my 
case, they know to format the packet and place the data into a POP-3 mailbox for me to collect. 


Having so many satellites means that most of the time there is about 80% coverage of the earth. If 
there is no coverage at a particular spot, it is likely that there will be within just a few minutes. 


Continued on page 17 
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16.44:S3Lo¢ software from 
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www.nisa.com 


Continued from page 16 


OrbComm currently has four Gateway Earth Stations (GES) located in the continental USA, with 
three more in South America. Other earth stations are located in Japan, Indonesia, and Italy. Additional 
base stations are planned for Africa and Australia to improve the performance of the system. 


Each of the ground stations is linked back to the manned control center in the eastern USA. 
Ground Stations 


The ground stations are effectively self-contained TNC and radio units combined into a single small 
package. The units that I have been using operate with a Motorola 68332 processor for controlling the 
radio and an AVR to wake up the CPU at appropriate times and to log data. 


The radio is advanced enough to periodically download a copy of the orbital elements for the satel- 
lites. It can then use this data along with the GPS receiver to know when to listen for a satellite and 
what Doppler offset to use. 


In my case, the units are programmed to sample the GPS positions a few times every hour and upload 
the data when the packet is full. As soon as a satellite is overhead, the radio powers up, locks to the 
satellite, and uplinks the GPS data. If there is no satellite passes for a while, the messages will just get 
stored until a satellite is available. 


Continued on page 18 
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Continued from page 17 


The units are able to work under very low power thanks to the strict power management. However, 
the radios do transmit 5W, which is ample for the distances involved. 


Performance 


What I have found with the entire system is exactly what I expected: the system generally worked well, 
at least in store-and-forward mode. Generally it took about 45 minutes for uplinked data to be 
downlinked in North or Central America and arrive at our office through the Internet, although there 
are occasions where the downlink must have come through one of the other base stations since the 
delay was about four hours. 


I also found that the uplink of data was never successful at highway speeds and would only uplink 
when I slowed down. This is probably the result of Rayleigh fading causing interference to the uplink 
signal. 


I really was amazed to be able to send telemetry packets to the satellite from my car when it was 
parked under a steel roofed carport. I guess that the packets must have been sent when the satellite was 
on the horizon; that is the only thing I can think of that allowed this to work. 


Conclusion 


I hope that I have shown is that Amateur Radio is making a difference in the wider world. Just think 
about the technologies that this system uses that Amateur Radio either developed or refined, such as 
microsatellites, packet radio, GPS tracking, store-and-forward satellites, and high speed data links on 


iF 


satellites. 
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